“Calhoun 


Institutional Archive of the Naval Postgraduate School 





Calhoun: The NPS Institutional Archive 
DSpace Repository 


Theses and Dissertations 1. Thesis and Dissertation Collection, all items 


1994-09 


Automation of hardware-in-the-loop testing of 
control systems for unmanned air vehicles 


Moats, Michael L. 


Monterey, California. Naval Postgraduate School 
http://hdl.handle.net/10945/43002 


This publication is a work of the U.S. Government as defined in Title 17, United 
States Code, Section 101. Copyright protection is not available for this work in the 
United States. 


Downloaded from NPS Archive: Calhoun 


Calhoun is the Naval Postgraduate School's public access digital repository for 


\§ D U DL EY research materials and institutional publications created by the NPS community. 
«iit Calhoun is named for Professor of Mathematics Guy K. Calhoun, NPS's first 


NY KNOX appointed -- and published -- scholarly author. 


LIBRARY Dudley Knox Library / Naval Postgraduate School 
411 Dyer Road / 1 University Circle 


http://www.nps.edu/library Monterey, California USA 93943 





NAVAL POSTGRADUATE SCHOOL 
Monterey, California 


Avan 





THESIS ww G 


AUTOMATION OF 
HARDWARE-IN-THE-LOOP 
TESTING OF CONTROL SYSTEMS 
FOR UNMANNED AIR VEHICLES 


by 


Michael L. Moats 
September, 1994 


Thesis Advisor: Isaac I. Kaminer 





Approved for public release; distribution is unlimited. 


ro DG QUALI? Lscrin.ub S 
SS 


natu 94 9 23 080 


D 








REPORT DOCUMENTATION PAGE OME Ne bree dias 


Public reporting burden for this collection of information is estimated to average 1 hour per response. including the time for reviewing instructions. searching data sources. gathering 
and maintaining the data needed. and completing and reviewing the collection of information. Send comments regarding the burden estimate or any other aspect of this collection of 
information. including suggestions for reducing this burden. to Washington Headquarters Services. Directorate for information Operations and Reports. 1215 Jefferson Davis Highway. 
Suite 1204. Arlington. VA 22202-4302. and to the Office of Management and Budget. Paperwork Reduction Project (0704-0188). Washington. OC 20503. 


1. AGENCY USE ONLY (Leave blank) 2. REPORT DATE 3. REPORT TYPE AND DATES COVERED 
September, 1994 Master’s Thesis 


@. TITLE AND SUBTITLE 5, FUNDING NUMBERS 
AUTOMATION OF HARDWARE-IN-THE-LOOP TESTING OF CON- 
TROL SYSTEMS FOR UNMANNED AIR VEHICLES 
6. AUTHOR(S) | 
Michael L. Moats 




























8. PERFORMING ORGANIZATION 
REPORT NUMBER 







7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 
Naval Postgraduate School 
Monterey, CA 93943 









10. SPONSORING/MONITORING 
AGENCY REPORT NUMBER 


9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 





11. SUPPLEMENTARY NOTES 
The views expressed in this thesis are those of the author and do not reflect the 
official policy or position of the Department of Detense or the United States Government. 


12a. DISTRIBUTION/AVAILABILITY STATEMENT 12b. DISTRIBUTION CODE 
Approved for public release; distribution is unlimited. 























13. ABSTRACT (Maximum 200 words) 
Modern computing advances allow the aerospace controls engineer the ability to design, test, and implement au- 


tomatic control systems for air vehicles with breath taking speed and accuracy. This work examines the automation 
of the hardware-in-the-loop testing and implementaion of autonomous controllers for Unmanned Air Vehicles. Ex- 
traordinary interest is generated in this subi. -t considering automation results in hardware-in-the-loop testing within 
days of completing a controller design. Th: ntire automation process is presented, from design of the controller to 
implementation on a particular control platform to hardware-in-the-loop testing of the controller. This accomplishes 
control design and implemention in a matter of months compared to a few years or more before automation. 


















14. SUBJECT TERMS 


Hardware-In-The—Loop Simulation, HITL, H Infinity Control, Real-Time Simulation, 109 
AROD, Pulse Width Modulation, PWM, AC100, MATRIXx, SystemBuild 


17. SECURITY CLASSIFICATION 18. SECURITY CLASSIFICATION 19. SECURITY CLASSIFICATION 20. LIMITATION OF ABSTRACT 
OF REPORT OF THIS PAGE OF ABSTRACT 
UNCLASSIFIED UNCLASSIFIED UNCLASSIFIED UL 


NSN 7540-01-280-5500 Standard Form 298 (Rev. 2-89) 
Prescribed by ANS! Std. 239-18 
298-102 








Approved for public release; distribution is unlimited 


AUTOMATION OF 
HARDWARE-IN-THE-LOOP 
TESTING OF CONTROL SYSTEMS 
FOR UNMANNED AIR VEHICLES 
by 
Michael L. Moats 
Lieutenant, United States Navy 
B.S. University of Colorado, Colorado Springs, 1986 


Submitted in partial fulfillment of the 
requirements for the degree of 


MASTER OF SCIENCE IN AERONAUTICAL ENGINEERING 
from the 
NAVAL POSTGRADUATE SCHOOL 


September , 1994 


Michael L. Moats 





Approved by: 











aniel J. 
Department of Aeronautics and Astronautics 





ABSTRACT 


Modern computing advances allow the aerospace controls engineer the ability 
to design, test, and implement automatic control systems for air vehicles with breath 
taking speed and accuracy. This work examines the automation of the hardware- 
in-the-loop testing and implementaic’ — 4. t»nomous controllers for Unmanned Air 
Vehicles. Extraordinary interest is genera’ 4 in this subject considering automation 
results in hardware-in-the-loop testing within days of completing a controller design. 
The entire automation process is presented, from design >f the controller to imple- 
mentation on a particular control platform to hardware-in-the-loop testing of the 


controller. This accomplishes control design and implemention in a mat:er of months 


compared to a few years or more before automation. 
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I. INTRODUCTION 


The aeronautical controls engineer of the 90’s can design a dynamic aircraft 
model, verify its accuracy, design a control system, and implement the controller on 
a computer in a matter of a few months. Application software tools such as MATLAB 
with SIMULINK and MATRIX, with SystemBuild allow the design to be completed 
and tested at the block diagram level. In particular, Autogen and AC100 products 
developed by Integrated Systems, Incorporated allow for direct conversion of the 
block diagram to a fully implemented control system. This system can be tested 
real-time with hardware-in-the-loop while recording any or all of the state variables 
to verify performance. Before discussing the automation of the design process in 
detail, a brief outline of each step follows. 

The first step in the design process is to create a high fidelity nonlinear model 
of the aircraft which can be reliably trimmed and linearized throughout the full 


spectrum of required flight conditions. Such modeling is completed in four stages: 


e Developing the equations of motion. Sum all of the forces and moments involved 
and write the equations in terms of states to allow for easy convertion into a 


block diagram. 


e Creating a nonlinear model. Create a block diagram representation of these 


equations. 


e Creating a linear model. Trim the nonlinear model about the desired trim point 


and then linearize the model to obtain a linear model. 


e Validating the model. Use the data from an independent source to validate the 


model. 


The next step is to design a feedback controller. This is typically ar itera- 
tive procedure beginning with the design requirements. Usually requirements will 
be placed by the designer in terms of response time and overshoot for the desired 
controller. For example a heading controller may be required to achieve a ten degree 
heading change within 30 seconds and have a maximum overshoot of one degree. 


With the requirements on hand, the control design steps are: 


e Building a control synthesis model. The designer chooses which sensors to use 
and creates a synthesis model with the desired command inputs using the linear 


model. 


e Computing the control gain. A cost function is defined by the designer de- 
pending on the specified requirements and the method chcsen for computing 
the controller. The control gain is then calculated. The methods for computing 


this gain include: 


~ Linear Quadratic Regulator Theory 


—- H, Theory 


e Check the command and control loop bandwidth: The bandwidth is plotted 
for each of the command loops and checked against the specified requirements. 
The control loop bandwidth is also checked and compared to the bandwidth of 


the chosen actuators. 


The cost function defined above includes some weighting factors. These are the 


design knobs which the designer uses to create the desired controller. If the control 


and/or command bandwidths are too large or too small, the designer adjusts these 
weights and re-computes the control gain. This typically involves many iterations. 
The designer may also find it necessary to move the zeros placed in the synthesis 
model and restart the iterations from that point. 

The next step in the design process is to test the feedback system. SIMULINK 
and SystemBuild have built in capabilities for performing these tests. The first test is 
to close the loop with the linear model and the controller. The resulting closed-loop 
system is then tested. Next the controller is connected with the nonlinear model and 
tested. 

An important step in the testing process is to develop an accurate model of the 
actuators. If the actuators are not modeled well, the software test of the controller 
may indicate that the controller works as designed while an hardware-in-the-loop 
test may show that the feedback system is unstable. This is usually caused by the 
actuators not being able to respond fast enough to commands. 

Once an accurate model of the actuators has been developed, the closed loop 
software test is repeated with the actuator models in the loop. If the actuator models 
are acurate and the controller design is correct, there should not be an apparent 
difference in the performance of the controller. 

The designed controller must be implemented on a platform capable of produc- 
ing the required control signals and reading the given sensor outputs. Since personal 
computers, or PCs have become very cost effective, the typical controller implementa- 
tion is a PC microprocessor with input/output, or I/O cards. The I/O cards available 
can produce or read analog voltages, pulse width modulated, or PWM signals, and 
serial communications to name a few. The control algorithm is then programmed 


using a high level language such as C or FORTRAN and then compiled to run on 





the chosen PC. During programming, careful consideration must be given to initial- 
izing and using the I/O cards. Timing is the most critical part of the programmed 
controller. 

The next step is hardware-in-the-loop , or HITL simulation, where the feedback 
system is tested with some of the actual hardware which will be used to control the 


aircraft. HITL testing is done in one or more stages. 


e Actuators and Sensors: The first stage is to include all of the actuators which 
receive control signals directly, such as the elevators, rudder, and ailerons. The 
sensors which measure the results of these actuators must also be included in 
order to close the loop. After this initial test, other less critical actuators may 


be added. 


Control Inputs and Sensors: A possible second stage is to include the control 
input device, such as a joystick for an unmanned aircraft, into the loop along 


with the sensors required to measure the control inputs. 


The most critical part of any hardware-in-the-loop test is calibration of the sen- 
sors. The controller includes an algebraic conversion of the measured sensor outputs 
to a signal that can be used directly by the controller. This algebraic conversion 
requires calibration by determining the correct conversion constants. 

The ultimate test of a designed controller is the flight test. Budget considera- 
tions demand that the controller work perfectly the first time. The flight test phase 


is usually performed in three stages: 


e Test Stand: The first flight test is usually done in a laboratory facility on a test 


stand which allows some degree of movement while restricting flight so that the 


vehicle can not be damaged. 





e Tethered Flight: The next stage is typically a teathered flight. In this manner, 
an experienced pilot can be standing by with a manual override switch to allow 


direct manual control of the vehicle in the event of a problem. 


e Actual Flight: The final and ultimate test of the control design is the au- 


tonomous flight test. 


The main purpose of this report is to discuss the automation of the design 
process which has just been summarized. The main tool used in this process is 
Integrated Systems, Incorporated’s AC100 package. Once the designer develops a 
plant model and a controller using MATRIX and SystemBuild, AC100 can be used 
to implement and test the controller on actual hardware with a few pushes of a 


button. 





II. DEVELOPING EQUATIONS OF MOTION 


A. BACKGROUND 


There are several unmanned air vehicles, or UAV’s, currently in use « a 
Two of these are discussed in this report, the Bluebird and the AROD. The AROD 
is described in the next section and the detailed development of its equations of 
motion and computer modeling are covered. The Bluebird is discussed next. It is a 
small conventional aircraft acquired as a test bed for testing guidance and navigation 


systems. For a complete description and the development of the equations of motion 


for Bluebird, see [Ref. 1]. 
B. DESCRIPTION OF AROD 


The Airborne Remotely Operated Device, AROD is a vertical take-off and land- 
ing, VTOL, aircraft originally designed by Sandia Research Laboratory in Albu- 
querque, New Mexico. The AROD has been the subject of several theses at NPS and 
this report expands on the work started by those individuals. For a detailed descrip- 
tion of AROD refer to [Ref. 2, 3] and the Sandia Lab papers (Ref. 4, 5] as well as 
the references therein. The AROD is shown in Figure 2.1 and its characteristics are 
tabulated in Table 2.1. 

A combination of the control vanes are used to exert the desired control forces 
on the AROD. Roll control is obtained by deflecting all four vanes in the opposite 
direction of the desired roll. Pitch and yaw are obtained by deflecting the pair of 


vanes in the y and z planes respectively. The numbering of the vanes is shown in 








Figure 2.1: Airborne Remotely Operated Device, AROD 


Figure 2.2 and the combinations of vanes required for roll, pitch and yaw are given 
in Table 2.2. 

There are three dynamic coupling effects which must be considered when de- 
signing a control system for AROD. The first is the gyroscopic coupling due to the 
large angular momentum of the propeller. Another dynamic coupling exists between 
the vehicle attitude and the altitude-rate since thrust vectoring is required for trans- 
lational movement. This coupling is depicted in Figure 2.3. The third effect is caused 


by the propeller. As the air is accelerated through the propeller, it is also deflected 





TABLE 2.1: PHYSICAL CHARACTERISTICS OF AROD 








Exit Radius SiC TS 
Tapered Rear 
8000 rpm 


Inlet Diameter, A 29.25 in 









Engine Speed, Nom. 6500 rpm 
Tip Speed, Max. 838 fpm 
Tip Speed, Nom 680 fpm 


6147 slug f 
Prop Mass Moment of Inertia, I,z | 0.0311 slug — f? 









TABLE 2.2: VANE DEFLECTION COMBINATIONS FOR POSITIVE ANGLES 


[__| Vane Combination | 
Roll, @ | VithwtVw+M | 
| 

| 











slightly causing a swirl effect. The result is that the air mass strikes the control vanes 
at an angle proportional to the angular rate of the propeller. This creates a rolling 


moment which is dependent on the throttle input. 








Vz 
Figure 2.2: AROD Direction of Positive Vane Deflections 
C. EQUATIONS OF MOTION 


1. Notation 


The notation used in this report is consistent with the previous work on the 


AROD, see [Ref. 2] and references therein. Consider Figure 2.4, here: 
e {A} represents the coordinate system with basis vectors, z4,y4, and 24. 
e “Pg represents the position of point Q, expressed in {A}. 
e “VQ represents the velocity of point Q, measured in {A} and expressed in {A}. 


e 7(A4Vo) represents the velocity of point Q, measured in {A}, and expressed in 
{B}. 


e 4R is a rotation matrix from {B} to {A}, also called a direction cosine matrix. 


A free vector in one coordinate system, is a vector that can be moved parallel 





T*cos(Y) is 


All thrust used for lift 


available while 
T is used for 
lift. T*sin(Y) is 


used to move 
in y direction 





Figure 2.3: Coupling Between Altitude and Attitude 


to itself without change. As a result, it can be expressed in another coordinate 


system by using the rotation matrix. For example: 
4(?Vq) = BR (?Va) 
e 4(z is the angular velocity of the {B} coordinate system with respect to {A}, 
and expressed in {A}. 


e 8(40 8) is the angular velocity of {B}, with respect to {A}, and expressed in 
{B}. 


e Additional information can be added to the subscripts i.e., 4 Pgo is the position 


of the origin of {B}, expressed in {A}. 
2. Coordinate Systems 


In order to derive equations of motion for a rigid airplane, the following 


coordinate systems and assumptions will be used: 


10 








Figure 2.4: Relative Position of Coordinate Systems 


e {U} represents the inertial tangent plane coordinate system attached to Earth. 


{B} represents the body fixed coordinate system. 


{W} represents the wind axis coordinate system. 


e All sensors are located at the c.g. ( This assumption is used for simplification 


only and can be relaxed as shown in [Ref. 2] ) 
e The mass of the aircraft remains constant. 


e Given a vector v, its derivative with respect to {B} is denoted as (v) 


and its derivative with respect to {U} is denoted as (v) 


The {B} coordinate system is a right handed system with Xg defined as the thrust 


axis. A positive roll rate, p, is clockwise when looking in the positive X direction. 


1] 


The positive direction for Yg, the pitch axis, is out the right wing . A positive pitch 
rate, g, is defined as clockwise looking in the positive Y direction. The Zg axis is the 
yaw axis, and a positive yaw rate, r, is defined as clockwise, looking in the positive 
Z direction. 

The {W} coordinate system is defined with Xw aligned with the wind 
incident on the aircraft. The angle a is the angle formed by the body x-y plane and 
the positive Xw axis. The angle 8 is the angle formed by the body x-z plane and 
the positive Yw axis. 

To simplify the notation in places where it becomes cumbersome, the fol- 


lowing definitions are introduced: 


© vg represents the velocity of an arbitrary point, Q, measured and expressed in 


{U}. 


e vgo represents the velocity of the origin of {B}, measured and expressed in 


{U}, ie, “Veo = vBo. 


© vg represents the acceleration of {B} with respect to {U}, measured and ex- 


pressed in {U}. 


e *vQ represents the velocity of point Q, measured in {U} and expressed in { B}, 
i.e., B(YVg) = Bug. 

@ wg represents the angular velocity of {B}, measured and expressed in {U}, i.e., 

Un, B = Wp. 

Bw, represents the angular velocity of {B} measured in {U}, and expressed in 


{B}, ie., 2(¥Ng) = Bug. 


e 0 represents the appropriate size matrix with all elements equal to zero. 


12 








e /,, represents the identity matrix of dimension n. 
3. Spatial Orientation Using Euler Angles 


The spatial orientation of a rigid body (Ref. 6] can be defined by the three 
Euler angles, ®,9, and W called roll, pitch and yaw and defined in Figure 2.5. The 
Kuler angles, in turn, can be used to define a rotation between two coordinate systems. 


This rotation is obtained using Euler’s theorem: 


Any number of rotations about different axes through a point must, in 


the end, remain equivalent to a single rotation. 


For the case of conventional aircraft, a 3-2-1 rotation sequence is used [Ref. 7], 
where the aircraft is yawed, pitched, and then rolled. In this case, 9 is small, and in 
steady state flight is equal to the angle of attack, a. The angle ® can be expected 
to be anywhere from + 60 deg in normal flight and can be anywhere from + 180 deg 
in acrobatic flight. VY represents the heading of the aircraft and of course can range 
from 0 to 360 deg. This euler angle rotation was used in modeling the Bluebird. 

Euler angle rotations have an inherent singularity point when considering 
euler angular rates. The singularity point for a 3-2-1 rotation is © = 90 deg. There- 
fore, the adopted convention for AROD is a 2-3-1 rotation which has a singularity 
point at V = 90 deg. 

The transformation from inertial coordinates{U}, to body coordinates {B}, 


is carried out as follows, and is shown in Figure 2.5. 


1. The inertial coordinate system is represented by the vector “V, with the 
components x, y, and z. The first rotation is made about the y axis through an 


angle ©. Now the vector is expressed as 7V with the components z2, y2, and 22. 


13 








Figure 2.5: Y-Z-X Euler Angle Rotation Sequence 


Since the rotation was about the y axis, the y2 component remains unchanged. 
The resulting elemental matrix is: 


M(®)=| 0 1. 0 


sinOQ 0 cosO 


(2.1) 





cosQ8 0 —sin® | 


. Now the rotation is made about the new z axis, z2, through an angle V. This 
results in a third coordinate system with the vector expressed as *V, and having 
components z3,y3, and z3. This rotation does not change the z3 component. 


The resulting elemental matrix is: 


cosW sin¥ 0 
M(¥)=] -—sin¥Y cosW 0]. (2.2) 
0 0 1 
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3. Lastly, the rotation about the r3 axis through an angle ® is made to give the 
vector expressed in body coordinates, 3V. Now the resulting elemental matrix 
is: 

] 0 0 
M(®)=1]0 cos® = sin® |. (2.3) 
0 -—sin® cos® 


When the matrices are multiplied together in the correct sequence, M(®)M(V)M(9), 


the result is the 2 R direction cosine matrix, expressed in terms of Euler angles as: 


cosV cosO sin — cos sinO 
—cos® sinW cosQ + sin®cosO cos@cosW cosPsin¥cosO +sin®cosO | (2.4) 
sin® sinY cosO + cos®sinO -—sin®cosW —sin®sinW sinO + cos® cosO 


The next step is to develop the kinematic differential equations that describe 
the change in Euler angles with time. Following the method used in [Ref. 7], the 


matrix of differential equations, 2, can be written as a sum of individual Euler angle 


rates: 
26 0 0 
Q= mo 0 | + mom 0 | + momo 49 | (2.5) 
0 ay 0 


When the matrix algebra in Equation 2.5 is done, the resulting kinematic differential 


equations for p, g, and r are given as: 
p 1 sinW 0 $ 
q|=10 cos® cos¥ sin® 0 (2.6) 
r 0 -sin® cosW cos® v 


The matrix on the right hand side of Equation 2.6 is invertible for all ¥ # =, and 


can be used to solve for the Euler angle rates, 6,0 and VW: 


® 1 --cos®tanV sin® tan ¥ p 
O/=|0 csOsecW —sin® sec¥ qj. (2.7) 
v 0 sin ® cos ® e 


The time history of the Euler angles can be obtained by integrating Equation 2.7. 


15 


4. Derivation of the Equations of Motion 


For a general aircraft model with six degrees of freedom the derivation of 
the equations of motion can be broken into two parts. The first part is the motion 
of an arbitrary rigid body in free space. This motion depends only on the linear 
and angular momenta of the rigid body which can be divided into linear and angular 
equations. The second part is an examination of all of the forces acting on tha rigid 
body. These forces are aerodynamic, gravitational, and propulsive. The aerodynamic 
and propulsive forces are specific to the aircraft being modeled and are characterized 


by the stability and control derivatives described later in this thesis. 


a. Linear Equations 


The linear equations are developed using Newton’s Law, F = ma. Be- 
cause the sensors are attached to the body of the aircraft, the equations are written 
in the {B} coordinate system. Matrix equations avoid the repetition of writing equa- 
tions in terms of x, y, and z. First the position of the aircraft center of gravity, or 
c.g., (the origin of {B}) is determined as Pgo. Next Coriolis’ theorem is applied 
to obtain linear velocities for the aircraft. Coriolis’ theorem is then applied a second 


time to derive the equation for linear accelerations. First, define: 
UVao =" Pro. (2.8) 
Both sides of Equation 2.8 are premultiplied by 2R to get: 
BR’ Veo = BR’ Pao 


or 


Bygo = 8 Po (2.9) 
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Now consider Coriolis’ theorem: 


A= SA tux A, (2.10) 


where A and LA use the notation for derivatives previously defined in Section 1 The 
term w x A represents the difference between the relative velocity as measured from 
the rotating and non-rotating axes [Ref. 8]. 


Equation 2.10 is applied to vg in Equation 2.9 to get: 


B 


Bi50 = £ vp + Bwp x? vp, (2.11) 
Newton’s law can now be written as: 
UF = ma 
= mvgo, (2.12) 


where “F is the total external force applied to the aircraft c.g. Equation 2.12 is 


premultiplied by 2 R to obtain the result: 


BR => m ER VSBO 


= m*dogo. (2.13) 


when Equation 2.11 is substituted into Equation 2.13, the final result for ? F is: 


d® 
aN mF vp t+ Bwp x? vp) 
B 


m 77; vpa+m Bug x5 UB. (2.14) 


b. Angular Equations 


The angular equations are derived using Euler’s Law for preservation of 


angular momentum. These equations are derived in the {B} coordinate system for 
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the c.g. by applying Coriolis’ theorem to the equation for Euler’s Law: 
ULgo =" Ngo. (2.15) 


where Lao is the angular momentum of the aircraft and U Ngo is the total external 


moment applied to the aircraft c.g. Then, premultiplying Equation 2.15 by BR gives: 
Biao a BR’ Ngo, (2.16) 
Using Coriolis’ theorem in Equation 2.10, Bh 30 can be rewritten as: 
Bj dp B B 
Lo = di Lpo + “wp x “Lego, (2.17) 


The angular momentum, # Lo, is defined as the sum of the product of the inertia 
tensor, Ig, and the body’s angular velocity, 2wg, and the product of the inertia 


tensor Ip, and the angular velocity of any rotating parts wa, or: 
Br S Tp Bap + Ip Bwp, (2.18) 


where Ip and Bwp are the moment of inertia and the angular velocity of the rotating 
part, respectively. Note that additional rotating parts can be accounted for by adding 


additional terms to Equation 2.18. With a single propeller the equation becomes: 
Br © Ig we + Ip (Bwp + Bwp), (2.19) 


where Jp and ?wp are the moment of inertia and the angular velocity of the propeller, 


respectively. When this term is substituted into Equation 2.17, the result is: 
. d 
Pleo = qlis we + Ip(Bwp + Bwp)) + Bw x (Ip? we + Ip(Pwe + Bwp)), (2.20) 
For simplification, define the total inertia tensor, [7 as: 
4 
Iy = Ip + Ip (2.21) 
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Collecting terms, Equation 2.20 becomes: 


. d 
Bhigo = qin we + Ip? wp) + Fup x (Ip? wp + Ip? wp), (2.22) 
Carrying out the differentiation in Equation 2.22 yields: 


Biso = Ip Pup + Ip Pup + Bwp x (Ip?wp + IpBwp). (2.23) 


Since £(8wp) = Bap and £(Bwp) = 0 if we assume a constant angular velocity for 


the propeller, Equation 2.23 can be simplified to: 

Bigo = Ip ewe + Bwp x (Ir?wp + IpPwp) (2.24) 
Now the result in Equation 2.24 can be substituted into Equation 2.16: 

BNgo = IpPwp + Bwp x (IpPwp + [pBwp). (2.25) 


The term [p?wp can be disregarded if it is insignificant compared to Ig and Bug 
[Ref. 9]. This term is neglected in modeling the Bluebird see [Ref. 1]. For the case 


of AROD this term is significant and is not negi: -ted. 


c. State Equations 


Now that the kinematic equations of motion have been developed in 
matrix form, these equations can be assembled into a state-space representation of 


the equations of motion. First, Equations 2.14 and 2.25 can be written as: 


| BP | _ | m 47 up +m (wp x vp) | (2.26) 
BN TyP wp + Bug x (Ir8wp + IpBwp) 
Equation 2.26 can be rearranged to yield: 
gine] [ect 91 a 
dt | [7 wp —Bup x (Ip8wp + IpBwp) +2N) 
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The terms on the left hand side of Equation 2.27 can be normalized by multiplying 


by + and Pe with the final result: 


d Bye —Fwp x? vp + aE 


wp Xx (Ip8wp + IpBwp) + I7'FBN 
d. Forces and Moments 


Equation 2.28 gives the kinematic equations of motion for a rigid body. 
The next step is to examine the forces ? F and moments 8 N acting on the rigid body. 
These forces and moments are due to gravity, aerodynamics, and propulsion, and are 


written as: 


BR a 8 Forav + ®Fprop + ®Faero (2.29) 
BN B Nprop + ® NazRo 


Gravitational Forces: The gravitational forces acting on the air- 
craft, 8 Foray, can be determined by rotating ’ Feray with the appropriate rotation 


matrix, where: 


0 
“Forav=| 0 |. (2.30) 
mg 
Then: 
B Forav = BR” Forav- (2.31) 


Aerodynamic Forces and Moments: The aerodynamic force and 
moment terms are determined by using first-order Taylor series expansion around a 
given nominal operating point. This operating point is the state chosen to represent 
the aircraft’s flight condition. Each term in the series is a partial derivative of 3 F or 


BN with respect to the aerodynamic variables, 5, a, B, p,q, 7 (Ref. 7, 10): 


FuerRo = 6F pz’ + 6 Fz! + dFyA + Fo. (2.32) 
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Similarly, moment terms can be written as: 
Naero = 6Nzt' + 6Nzt' + BNaA + No, (2.33) 


where 2’ is given by: 


, (2.34) 


and z’ is given as: 


i! = | é (2.35) 


Notice that z’ contains only two elements. The other derivatives are negligible and 


therefore not included. Control inputs are represented by the vector A: 





be 
5, | (2.36) 


where 6,, 6,, and 6, are the elevator, rudder, and aileron inputs, respectively. Equa- 


tions 2.32-2.36 can now be combined as follows: 
Oc ., a 


"Faro | _ 554 OC + —2'+=—A+Cro} (2.37) 
W Narro WLGg Oz! OA Ran 


where g = z pV?, S = diag{S, S, S, Sb, Sc, Sb}, and C is the matrix of non-dimensional 
stability derivatives differentiated with respect to the terms defined in Equation 2.34, 
2.35, or 2.36. 2& is defined as: 


dr! 
Cry Crug Cre Ch 
Cy, Cy, Cy, Cy, 


3C 4 | Coy Cro, Cr. Cro, Co, Co, (2.38) 


Oz! Cig: “Cig. Cy Cy “Cie Cr 
Ce Oa Cx Ce Ce. Cx 
nu Ch 8 Ge. Crp Cn, Cx 


g¢ is very similar to gc except that only the & and 8 terms are normally significant, 


leaving a 6 x 2 matrix rather than a square matrix. The term ae is defined as: 


Ci, Cre Cry. 


Cy, Cy, Cr,, 
OC a | Cop, Ds Ds 
— = 'e v: a . 2.39 
oA Cis, igs tps 20) 
Mé,. Mb, Mg 


Cro = ’ (2.40) 


Cro 
Cho 


representing conditions in trimmed, balanced flight. This definition is similar to the 
definition used by Roskam [Ref. 9]. In other references, the term Cro can refer to the 
nominal value of the coefficient at a = 0. However, in the Taylor series expansion 
it is more natural to use the first definition of Cro; therefore, it will be used in the 
following derivation and modeling. The stability and control derivatives are usually 
computed in the wind axis coordinate system, {W}. The transformation from {W} 
to {B} is performed in the same fashion as the Euler angle transformations mentioned 
earlier. The rotation matrix, 3,R, is a function of a and #, and is expressed as: 


cosacos$ —cosasinf —sina 
PR= sin ( cos 3 0 (2.41) 
sinacosf -—sinasin§ cosa 
The rotation from {W} to {B} is made by premultiplying the force or moment vector 
by &R. 


Since lift and drag are defined as positive along the negative zg and rg 
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axes, we define Fagro and Narro as: 


—D l 
FAERO = Y | and NaERo = | m | : (2.42) 
-L n 





The negative sign on D and L can be moved into the S$ matrix for convenience, so 


that the new matrix is: 
S= diag {—S, 5S, —S, Sb, Sc, Sb} (2.43) 


In order to write Equation 2.37 in state space form, state variables must be defined. 


The most commonly used notation to use for the state vector is to use: 


(2.44) 


s~eomvecéder 


However, the terms z’ and z’ in Equations 2.32 and 2.33 cannot be used directly as 


states. It is easy to define: 


M':z—7' (2.45) 
where: 
111 6 e¢ 6b 
M' = diag{ —, —, —,—, —, — 
diag{ Vn’ Vn’ Va? V5? V4" av,3 (2.46) 
and: 
0 sz 0 000 
M = - (2.47) 
00 +000 
T 


are matrices of appropriate dimensions. The complete expression for ?F agro and 


B Nagro can now be written as: 
BFarro|_.a|%R 0 OC ,,  ,9C,,. , OC 
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and can be substituted into Equation 2.28. 
Propulsive Forces and Moments: The propulsive forces and mo- 
ments, ® Fprop and ? Nprop, are computed directly in the body coordinate system 


{B} and are expressed as: 


Tx 
8 Fprop = | Ty | ; (2.49) 
Tz 
and: 
T, 
 Nprop = | Twn | ; (2.50) 
gh 


where the 7;’s represent the forces or moments due to thrust. Computation of propul- 
sive forces and moments depends on each particular engine installation, and must ke 
determined for the individual aircraft modeled. For the AROD, the thrust is aligned 


in the Xg direction and located at the c.g. yielding: 


Tx 
® Fprop = | 0 | (2.51) 
0 
and: 
T 
? Nprop = | 0 | : (2.52) 
0 


Equations 2.31, 2.51, and 2.52 can now be substituted into Equation 2.28: 


d Bugo —Fwex 0 Bygo 
ll Bug | 7 0 ~ 8 IF (Fw x es | Bue |+ 
bh 0 BP 
Lo on [ay] 


BF 8 Forav 3 F prop 
Lew J={ [ae ]+[ enpace [ort 


wR 0 ~O aC ange OC ngs ac 
0 BR -G5{ Cro + 85M'x + 2EM'z + SSA } bo. (2.54) 


where: 
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e. Complete Equations of Motion 


In order to write Equation 2.28 in state space form, the terms associated 


with z’ must be collected and moved to the left hand side, along with the other time 


derivative terms, Figo and Bug. Let: 
BR 0 h 0 
B w 4 
fe and M;*=j ™ ail 2.55 
w 0 BR I | 0 Piet ( ) 


then the complete non-linear equations of motion for any aircraft can be expressed 


in state space form as follows (Ref. 11]: 


d [ ?vso . —Bwpx 0 
— =X 
dt Buyp 0 —3 JF) (Fup x (FlpPwe + Ip wp)) 


2 BuBo B Forav 
M714,7q5 2M’ | | | +Mi*) | ; 
B 


BF pro = 
” | b+ #TGS(Cr + SA) , (2.56) 
8 Nprop 
”U Peo = Y RB vg, (2.57) 
and: 
A = S(A)Pwp, (2.58) 
where: 
@ 
A=|0 (2.59) 
Vv 
1 —cos®@tanV sin® tanV 
S(A)=| 0 cos®sec¥ —sin® sec¥ (2.60) 
0 sin ® cos ® 
and: 
x=Ig- My Tas EM. (2.61) 


P is the position vector of the aircraft, and S(A) is the matrix of kinematic differential 


equations based on Euler angles. 
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Ill. COMPUTER MODELING 


Now that the full non-linear equations of motion have been developed, the next 
step is to model the aircraft on a computer. Notice that Equations 2.56, 2.57, and 
2.58 are in a generic format. That is, they could be used to represent the AROD 
or the Bluebird or any propeller driven aircraft provided the correct values are used 
for the stability and control derivatives, aC aC. and a. as well as the forces and 
moments due to thrust, ?Fppop and ®Npprop. For this reason, it is convenient to 
create a model which accepts these values from a generic input file. This allows the 
same model to be used for different aircraft by simply changing the input data to 
correspond to the new aircraft. Validation of the model can then be accomplished 
by entering the appropriate data for a well known aircraft, such as a Cessna, and 
comparing the results of the model to existing data. 

For this report it was desirable to begin with an existing computer model that 
had already been tested in hardware-in-the-loop simulation so that the results could 
be compared. The model and controller chosen for the AROD were developed and 
tested by N. Sivashankar. The SystemBuildmodel he developed is explained here 
since he chose not to present it in his report [Ref. 3]. For his hardware-in-the-loop 
test, he developed C code for the controller to run on a 386 PC and developed a 
model of AROD in VisSim to run on a 486 PC. His hardware-in-the-loop setup is 
outlined later in Chapter VI Section A and in his report. 

The SIMULINK model developed in this section was not used to develop a con- 


troller and is presented here as an example of how to implement the equations of 


motion in a SIMULINK block diagram. For an example of how to implement these 
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equations in SIMULINK for the Bluebird see (Ref. 1]. 
A. BASIC NONLINEAR MODEL 


The basic nonlinear model is essentially the same for both SIMULINK and Sys- 
temBuild. The state derivative equations, Equation 2.56, are implemented and fed 


into an integrator block which feeds back into the derivative equations. 
1. Basic SIMULINK Model 


The SIMULINK model is shown in Figure 3.1, and is simply a block repre- 
senting the state derivative equations, Equation 2.56, and an integrator block in a 
feedback loop. The SIMULINK implementation of the equations of motion is simpli- 
fied by using a MATLAB function block. The program listing for this function block 
is given in Appendix A. Notice that the stability and control derivatives as well as 
the forces and moments due to thrust are found in a separate MATLAB script file. 
Appendix A shows this file with the values for AROD in a hover. This MATLAB 
function has deliberately not been optimized to clearly show how the equations of 
motion are implemented. The forces and moments due to thrust were measured by 


B. Stoney, [Ref. 12], and are given by: 
Tprop = 0.0297 65m — 104.7, (3.1) 


and: 


lprop = —0.0542 Tprop — 0.9138, (3.2) 


2. Basic SystemBuild Model 


The state derivative equations could be implemented on SystemBuild in a 


similar manner using an user code block. This involves writing a C or FORTRAN 
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Arod Non-Linear Model 


Ble} ete} el] 


4 | Integrators 





Mux! 


[4tu [sly [ew [7 fp [aly [afr [te }pm — fttftmeta | 12}psi 
Figure 3.1: SIMULINK Block Diagram of the Equations Of Motion 


function which is then linked into the SystemBuild diagram. The Bluebird model 
used for hardware-in-the-loop testing was developed in this way by J. Byerly. For a 
detailed explanation of how to implement the nonlinear model with user code blocks 
see his report [Ref. 13]. 

The nonlinear SystemBuild model of AROD is shown in Appendix B. The 
highest level consists of an input block for the constants, a SuperBlock for the aircraft 
kinematics, and a SuperBlock for all of the integrators. The kinematics SuperBlock is 
made up of three SuperBlocks representing the angular velocity equations, the linear 
velocity equations, and the Euler angular rates. The "L-dot_eq’ SuperBlock imple- 


ments Equation 2.58 directly. The lin_velocity.eq’ SuperBlock adds Equation 2.31, 
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Equation 2.51, and the first term of Equation 2.53. The result is the linear portion 
(the £3 yp portion) of Equation 2.56. The ’ang_velocity_eq’ SuperBlock implements 
the angular portion (the £5 up portion) of Equation 2.56. These values are then fed 


into an integrator block te determine the states. 
B. DISCRETE MODEL 


Since the AC100 Model C30 can not automatically generate code for a continu- 
ous system, v.1e model must be discretized. The goal is to simulate a continuous time 
system using a discrete tirne system. SIMULINK and SystemBuild do this by using a 
very small time step size with a continuous type integration algorithm. The continu- 
ous mode! can be discretized in SystemBuild with the "Transform SuperBlock’ option 
under the ’Build’ menu. Simply choose a small step time and the SuperBlocks are 
automatically transformed. The only difference is that all integrators will be replaced 
by ‘discrete’ integrators as shown in Figure 3.2, where T is the step time chosen for 


the discrete system. 


Figure 3.2: Transformation of an Integrator from Continuous Time to 
Discrete Time 


The step time must be evaluated with the model to determine the optimum 


step time. If the step time is too large the discrete system will not be an accurate 
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model. If the step time is too small the computation time necessary may slow down 


the discrete system to the point where it becomes unstable. 
C. TESTING THE MODEL 


The performance of the aircraft model must be verified. This is usually ac- 
complished by replacing the stability and control values with those of a well known 
aircraft such as a Cessna. The nonlinear model can then be trimmed at a given 
flight condition and the eigen values of the resulting linear model can be compared 


to existing data. 
1. Testing the SIMULINK Model 


The SIMULINK model of AROD presented here was trimmed for the hover 
condition and linearized. The resulting state-space matrices were identical to the 
state-space matrices determined by D. Kuechenmeister [Ref. 2]. Since this model 


was not used to develop a controller, no further testing was completed. 
2. Testing the SystemBuild Model 


The SystemBuild model of AROD developed by N. Sivashankar also pro- 
duced the same state-space matrices when trimmed and linearized for hovered flight. 


Refer to his report for more details on the testing of his model [Ref. 3]. 
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IV. DESIGN AND SOFTWARE TESTING OF 
THE CONTROLLER 


Now that a valid linear model has been developed, the controller can be designed. 
First, the designer determines which states or outputs are available for feedback and 
the control inputs to be used by the controller. For the AROD, the following states 


are measured: 


Pp 
q 
oo tor (4.1) 
0 
yp 
The inputs are elevator, rudder, aileron, and rpm (revolutions per minute of the 
propeller): 
be 
6, 
Alnput = 6 (4.2) 
beeen 


H. synthesis was used to design the state feedback controller. It is outlined in the 


next section. 
A. H,SYNTHESIS MODEL 


Consider Figure 4.1. Here w represents exogeneous inputs, z represents regu- 
lated outputs, P represents the plant model, y represents the actual plant output, 
and u, is the control input created by the controller. Using the notation in [Ref. 14], 


suppose the plant is partitioned as: 


Pu Pr2 
P= E 4.3 
| Pr Pr | (3) 
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Figure 4.1: H,, Synthesis Model 


so that: 


z=Pywt+Pyu y = Py wt Poo 
Then u and y can be eliminated using u = Ky, to obtain: 


= [Pu + Pr K (I — Paz K)"! Pr| WwW, 


This is normally denoted by: 
z=F,(P,K)w 


The H,. optimization problem is then: 


Find K which minimizes || F(P, K)|loo 


(4.4) 


(4.5) 


(4.6) 


(4.7) 








For the AROD, the input w, shown in Figure 4.1 is defined as: 


pitch command 


roll rate command 
WwW) = 
yaw command 


and the input wz is: 


wW2 = rpm input 


elevator 
u, = | rudder 


aileron 


[3] a(t 


The control commands are: 


The signals z, and 22 are: 


(4.8) 


(4.9) 


(4.10) 


(4.11) 


The designer changes the cost function weights W,, W2, and W; to obtain the desired 


bandwidth in the command and control loops. [Ref. 15] 


B. DISCRETE CONTROLLER 


The controller obtained using H,, synthesis has the following state-space repre- 


sentation: 


BAys — Yo) 


Z. = 
Cf u = C.2.+ De y2 ~ 


(4.12) 


Since C will be implemented on the digital computer it must be discretized first: 


_y (fe)Ka = AT Be (¥1 — yc) x 
Coit UK = Ce Lex + De Yau : 


where AT is the sampling period of the discrete time system. 


1. SystemBuild Discrete Controller 


(4.13) 


The SystemBuild implementation of a discrete controller uses a state-space 


block with the appropriate values as a matrix gain. The discrete controller for AROD 
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is shown in Appendix B Figure B.4. Notice that for this implementation AT has been 


multiplied into the B matrix instead of the control gain matrix. 
C. CLOSED-LOOP SOFTWARE TESTING 


The procedure for closed-loop testing of the controller is basically the same for 
both continuous and discrete time systems. The model and controller are connected 
as shown in Figure 4.2. Note that the discrete time controller could be tested with 
the continuous time model if the outputs of the discrete controller are routed through 
a zero-order hold before being input to the continuous model. This step is done auto- 
matically by SystemBuild when discrete and continuous SuperBlocks are connected 


within the same block diagram. 
1. SystemBuild Testing 


SystemBuild testing can be accomplished in several ways. All of these 
methods require the user to define a time vector. For a 40 Hertz controller the 
time vector might be: 


t = 0: 0.025 : 20; (4.14) 


Which produces a vector of 801 elements, starting at zero, spaced at 0.025 seconds, 
and ending after 20 seconds. The user can define an input vector in MATRIX, 
or connect signal generator blocks inside the model. The user then selects ’Analyze 
SuperBlock’ from the Build’ menu and enters the appropriate values. Typing ’sim’ at 
the MATRIX, prompt will begin the test and create a matrix of output values. The 
output matrix can be broken into vectors and observed using the ’plot’ command. 


The results of this test for the AROD are presented in [Ref. 3]. 
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Figure 4.2: Closed-Loop Block Diagram 





2. AC100 Model C30 Testing 


The discrete model can be tested on the AC100 Model C30 by following 
the procedures outlined later in Chapter VI Section B without connecting any of the 
hardware. The closed-loop connections are left in the model and the desired outputs 
are selected for the Interactive Animation display. The test results will be identical 
to those found above since the C30 processor is using the exact same closed-loop 


system as SystemBuild. 











V. MODELING ACTUATORS AND SENSORS 


For both the AROD and the Bluebird, all of the control surfaces are actuated by 
Futaba FP-S34 servo motors. These actuators where originally modeled by Sandia 
Labs as a second order system with ¢ = 0.6 and w, = 20 radians. 


w? 


z (5.1) 


Hi) s?+2C wp $+?’ 


This section examines the development of an accurate model for these actuators. 


A. ACTUATOR STEP RESPONSE 


The step response of a system can be used to determine its transfer function 
[Ref. 16]. An example step response is shown in Figure 5.1. This response is typical 
for an underdamped second order system. To determine the transfer function, it is 
necessary to determine the values for M, and t,. 

The measured step response for the Futaba servos is shown in Figure 5.2 with 
the step response for the transfer function given in Equation 5.1. This step response 
was measured using the data acquisition feature of the ACi00 Model C30 and the 
test setup outlined in the next chapter. 


The values for M, and t, were measured as: 
M, = 0.1197 t, = .059 , (5.2) 


With these values a second order transfer function can be created by calculating the 
natural frequency w, and the damping ratio ¢ using the following formulae: 


In( My) 


° = TM, +a” 
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(5.3) 








Figure 5.1: Typical Step Response of an Underdamped System 


and: 
tan“ =e ) 
Wy = a —, (5.4) 
V1 — Ct, 
These calculations resulted in: 
w, = 19.94 ¢ = .559 , (5.5) 


Since the step response did not match well with the step response of the calculated 


transfer function, a limited frequency response of the actuators was measured. 
B. ACTUATOR FREQUENCY RESPONSE 


The actuators were given a sinusoidal command input and the response was 
measured for frequencies of 1, 2, 3, and 4 Hertz. This procedure could have been 
duplicated for many more frequencies and the result would be a complete frequency 


response for the actuators. Figure 5.3 shows the frequency response at 3 Hertz. Each 
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Unit Step Reepones 





Figure 5.2: Step Response of Actuator and Second Order Model 


pole in a system will result in a total of 90 degrees of phase shift in the frequency 
response and half, or 45 degrees, of this shift occurs at the natural frequency [Ref. 
16]. Since the measured phase difference was approximately 180 degrees at 3 Hertz, 
the servo motors are more accurately modeled as fourth order systems. 

One possible fourth order model was determined and is given in Figure 5.4. 
Figure 5.5 shows the step response of the actuator and the fourth order model step 


response. 
C. ACTUATOR SENSORS 


Since the hardware-in-the-loop test will not cause the aircraft to move, aircraft 


sensors such as Inertial Measuring Units and Air Data Sensors can not be used. 
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Figure 5.4: Fourth Order Actuator Model 


Therefore the actuator positions must be determined. This is accomplished using an 


angular position sensor. The measured vane positions can then be used to determine 


the states of the aircraft so that an hardware-in-the-loop test can be preformed. 


The Futaba servos used do not include a separate position sensor. There is an 


internal control circuit which determines which direction and how far to move the 


servo based on the input signal. This input signal is a Pulse Width Modulated, or 
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Figure 5.5: Step RK -ponse of Actuator and Fourth Order Model 


PWM, pulse. The length of the pulse determines how far the servo is to turn. The 
previous hardware-in-the-loop test defined the throw of these actuators as being from 
0 to 200 degrees with the center position at 100 degrees. For this report the center 
position is defined as 0 degrees with full throw being plus or minus 100 degrees. A 
pulse width of approximately 0.3 milli-seconds corresponds to —100 degrees while 
a pulse width of approximately 2.4 milli-seconds corresponds to +100 degrees. The 
internal control circuit includes a small potentiometer in a feedback loop to control the 
motor. The servos were modified to include wires connected to the center and ground 
leads of this potentiometer as shown in Figure 5.6. The voltage across these two wires 
was then measured and divided by 5 volts, (the supply voltage), to determine the 


position as a ratio of the total allowable motion. 
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Figure 5.6: Actuator Sensors 


This sensor design depends on a constant 5 volts being applied to the positive 
end of the potentiometer. Since the same voltage also supplies power to the servo 
motor, this voltage actually changes slightly while the motor is turning. The servo 
motors draw approximately 8 milli-amperes of current when they are not moving and 
up to 200 milli-amperes when they are moving. The increased current draw during 
motion causes a drop in the supply voltage. Since the measured voltage is always 
divided by 5 volts the result is a noisy sensor position. This noise was measured as 
approximately one half of one degree in each of the four vanes. Since these sensed 
positions are used to determine the aircraft states, noise enters all of the states. The 
most pronounced effect of this noise shows up in the roll-rate p because all of the 
vanes add together to determine the aileron command. A 0.5 deg change in all of the 
vanes from one measurement to the next is equivalent to an aileron control surface 
movement of 80 degrees per second. 


To reduce this noise an additional wire was added so that the positive voltage 
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on the potentiometer could be measured at the same time as the center voltage. 


Figure 5.7 shows the new sensor wiring. 


Servo Motor High Tap 
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Control 
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Figure 5.7: Modified Actuator Sensors 


Now the ratio of the voltage measured from the ground to the center tap, over 
the voltage from the ground to the high tap gives the position as a percentage of 


total motion. 
VoenterTap 


= % of total motion (5.6) 
VitighTap 


The result of the new sensor design was an order of magnitude reduction in the sensor 
noise. Figure 5.8 shows the measured response of an actuator to a 2 Hertz sine wave 
input. The two wire response was measured prior to adding the additional wire to 


the sensor. The responses have been time shifted for clarity. 
D. UNDER-SAMPLING 


When continuous time signals are sampled at less than the Nyquist frequency 


and then reconstructed, the resulting waveform will have low frequency components. 
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Figure 5.8: Noise Comparison of Actuator Sensors 


This effect is known as under-sampling (Ref. 17]. 

A common example of under-sampling can be seen on television. The video 
camera essentially takes samples of the continuous time world and presents them in 
a discrete fashion. The human eye captures these discrete pictures and filters them 
so that the mind perceives continuous motion. When the video camera samples a 
rotating object such as a wagon wheel at a frequency less than the Nyquist rate for 
the rotation speed, the wheel may appear to turn backwards. Figure 5.9 shows how a 
37 Hertz sine wave, sampled at 20 Hertz, appears to be a 3 Hertz sine wave. The solid 
line is the continuous time sine wave, the asterisk symbols are the 20 Hertz samples, 
and the dashed line is the continuous time estimate of the samples. Notice that the 


reconstructed wave starts out negative. If this were a mathematical representation of 
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the wagon wheel, it would appear to turn backwards. The effects of under-sampling 


were eliminated in the AROD by the technique used to reduce aliasing which is 


discussed next. 


Unit Amplitude 





Oo 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 
Time (seconds) 


Figure 5.9: Under-Sampling of a Continuous Time Signal 


E. ANTI-ALIASING 


Sampling a continuous time signal results in an infinite train of ’copies’ of the 
sampled signal repeating at integer multiples of the sampling frequency [Ref. 17]. 
Aliasing occurs when the sampling frequency is such that these ’copies’ overlap. Fig- 
ure 5.10 shows the frequency response of an example signal, the sampled frequency 
response when sampled at 50 Hertz, and the sampled frequency response when sam- 


pled at 16 Hertz. The area between the triangles in the third response is called 
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aliasing. 
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Figure 5.10: Example of a Continuous Time Signal and Aliasing 


The effects of aliasing were reduced in the AROD hardware-in-the-loop test by 
adding an anti-aliasing filter. The sensor voltages were sampled at 1000 Hertz. The 
ratio of the two voltages was then fed into a third order low-pass Butterworth filter 
with a cut-off frequency of 10 Hertz. The output of this filter is then sampled at 40 
Hertz eliminating aliasing of any noise in the frequency range of interest. Appendix B 
includes the SystemBuild block diagrams for the anti-aliasing filters. The discrete 
low-pass filter was implemented using the ’FIIR’ command in MATRIX. The result- 
ing state-space matrix was then put into the SystemBuild block diagram. A separate 


filter was necessary for each of the four vanes. The state-space representation of the 
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filter is given by: 


Ar|B 
i= cr De | (5.7) 


The values for the discrete Butterworth low-pass filter state-space matrix were: 


1.9353D +00 —9.3912D —01 0.0000D + 00 | 2.9146D — 05 
1.0000D +00 0.0000D+00 0.0000D + 00 | 0.0000D + 00 
3.9353D +00 6.0879D —02 9.3906D — 01 | 2.9146D — 05 
3.9353D +00 6.0879D —02 1.9391D + 00 | 2.9146D — 05 


For the AROD, the frequency response of interest is from 0 to 3 Hertz (approx- 
imately 20 radians). The noise is estimated to have major components at 40 Hertz 
and harmonics of 40 since the PWM frequency is 40 Hertz. By sampling at 1000 


Hertz, we are assuming that the noise level is insignificant for frequencies above 500 


Hertz. The 10 Hertz cutoff frequency on the filter is designed to eliminate the noise 


at, and above 40 Hertz. 





VI. HARDWARE-IN-THE-LOOP TESTING 


The most critical phase of testing is the hardware-in-the-loop test of a con- 
troller. This is usually the final validation of a controller prior to an actual flight 
test. Typically this involves the actual control computer, actuators and some or all 
of the actual sensors. In the case of the AROT, the only sensors that can be used 
for this test are the servo-motor position sensors. Since no motion is involved, the 
IMU, GPS, and Air Data sensors would not produce usable data and therefore these 
sensors must be modeled along with the aircraft. 

The controller is typically implemented on a microprocessor capable of interfac- 
ing with the required hardware. In this case a 486 PC type computer is the intended 
control computer. For the first hardware-in-the-loop test, the AC100 Mode} C30 will 
serve as the control computer and as the plant model computer. Later, the con- 
troller will be separated and implemented on the 486 PC. Before discussing the new 


hardware-in-the-loop test setup, the previous test setup is presented for comparison. 
A. PREVIOUS TEST SETUP 


Before automation of hardware-in-the-loop testing, the aerospace controls en- 
gineer had to rely on computer scientists or know how to program in a high level 
language. For his hardware-in-the-loop test, N. Sivashankar wrote C code for the 
controller and for all of the necessary I/O drivers. His setup is presented in his re- 
port, [Ref. 3], and briefly outlined here. The complete setup is shown in Figure 6.1. 
The 386 PC runs the controller and outputs PWM signals to the vanes. The 486 PC 





senses the vane positions and computes the new states. The 486 PC then sends out 


analog signals to simulate the angular rate sensors and the euler angle sensors. 







sensor outputs 













PC386 
Controller vane geraves casa 


commands positions 


Figure 6.1: Previous Setup for Hardware—In—The—Loop Simulation 


The basic configuration of the 386 PC is shown in Figure 6.2. The 386 PC 
reads the analog inputs and converts the measured values to the correct units for 
the controller. The new control commands are then computed and sent out by the 


counter/timer board as PWM signals. 
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Figure 6.2: Configuration of the Data Acquisition Cards on the 386 PC 


The configuration of the 486 PC is shown in Figure 6.3. The vane sensor voltages 
are rei.1 by VisSim and then used to calculate the new aircraft states. The angular 
rates p, g, and r and the angles @ and w are then sent out as analog signals to the 
386 PC simulating the angular sensors. 

The most significant problem of this hardware-in-the-loop test setup was the 


speed of the AROD model. The VisSim model of AROD could not be run in real time, 
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Figure 6.3: Configuration of the Data Acquisition Cards on the 486 PC 


thus the controller had to be artificially slowed to 4 Hertz. The control algorithm 
was implemented in C-code as a function call which was driven by an interrupt. By 
design, this interrupt should have been at a rate of 40 Hertz. Since the VisSim model 
could not produce updated states at this rate, the interrupt was slowed to 4 Hertz. 
In this way, the controller performed as if it were running at 40 Hertz while actually 


running at 4 Hertz. For more details refer to [Ref. 3]. 
B. AC100 GRAPHICAL USER INTERFACE 


The new hardware-in-the-loop test setup utilizes Integrated Systems, Incorpo- 
1...ed’s AC100 Model C30. The AC100 Graphical User Interface, or GUI, is the 
workstation users link to all of the necessary software tools for modeling and testing. 


Prior to using the GUI, the user must ’source’ the ’acl00setup’ file. This is done by 


typing: 
’source $ISI/AC100/bin/acl00setup.sh’ 


at the unix prompt. This line can also be included in the ’.login’ file so that the 
’acl100setup.sh’ file is automatically run each time the user logs in to the workstation. 
This section assumes that the user has manually entered MATRIX, previously and 


is using the GUI for the first time now that the controller and model are complete. 
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The AC100 manuals refer to a model and controller as a project, [Ref. 18, 19, 20] 
with the project name being the name of the highest level SuperBlock in the diagram. 
There are standard files which must be present in the local directory for each project 
which have common names and the AC100 uses file extensions to separate files within 
a project. It is required to use a separate directory for each project to avoid using 
the project files from one project with the standard files of another project. 

The first of these standard files is the animation configuration file, (animation.cfg). 
Fach project will have a slightly different ’animation.cfg’ file, but it must have that 
name. To create this file, type ’makeproject’ at the unix prompt. The program will 
assume that the project name is the same as the directory name. If this is true, the 
user may accept all of the default settings by hitting ‘enter’ at each prompt. 

The next standard file is the ’target_config.cfg’ file. To create this file the user 
types ’retarget’ at the unix prompt. The user will be asked for the ’acl0Qhostname’ 
which is either "AC100’ or ‘america’. All of the remaining defaults should be selected. 
These files are only created once for each project. Now that these basic files have 


been set up, the user types ’acl00’ at the unix prompt to start the GUI. The GUI 


is used with the mouse and a single left mouse button click will activate the selected 


function. Figure 6.4 shows the AC100 GUI. 

The basic project file containing all of the required information about the model 
and controller including the input and output names is the real-time file. This file is 
created by selecting "Generate Real-Time Code’ from the SystemBuild ’Build’ menu 
and selecting the top level SuperBlock from the list. The file name can be specified 
and defaults to the name of the SuperBlock selected with the ’.rtf’ extension. The 


user can then exit MATRIX, and select ’Autocode’. 
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Figure 6.4: AC100 Graphical User Interface 


The next step is to build the Interactive Animation, or IA, display to be used 
during the hardware-in-the-loop test. The user will first need to determine which 
outputs to display and which inputs are desired for interaction ith the running 
model and controller. The user may need to add inputs and outputs to get the 


desired results. 
1. Interactive Animation 


The user clicks on the Interactive Animation Builder’ block to design the 
interface screen for working with the C30. The main IA picture for the AROD 
hardware-in-the-loop test is shown in Figure 6.5. Once in the IA Builder, the user 


double-clicks on any blank area to bring up the palette of display icons. The Inter- 
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Figure 6.5: Interactive Animation Display for AROD Controller 


active Animation section of the SystemBuild manual [Ref. 21] and the AC100 User’s 
Guide [Ref. 19] have details on all of the available icons and how to edit them for 
specific needs. The user then selects "Load RTF’ and enters the name of the ’-rtf’ file. 
The user then connects all of the icons to the respective inputs and outputs using 
the same connection procedures as in SystemBuild. If the user wants to display an 
input from one of the hardware connections, i.e., an A/D input, an extra output will 
have to be added to the model. Inside the model the input is then connected to 
the new output through an unity gain block. Once the IA picture is complete and 


all of the inputs and outputs have been connected, the user selects save. Additional 


52 








pictures can be created in the same manner. The main picture should be saved as 


*project_name.pic’. 

Additional pictures, such as a calibration screen, can be ‘chained’ using 
the ’process’ icon. The user must then edit the ’animation.cfg’ file and add ’file- 
name.pic’ under the "PROCESS_PICTURES’ section where ‘filename’ is the name 
of the ’chained’ picture. The IA calibration picture used for the AROD is shown in 
Figure 6.8. 


2. Hardware Connection Editor 


The Hardware Connection Editor, or HCE, screen is shown in Figure 6.6 
and explained in the AC100 Reference Manual (Ref. 18]. The individual hardware 
modules are further explained in the AC100 Supplemental Reference Manual [Ref. 
22]. The HCE is used to make connections to hardware and also to the IA picture. 
All connections to the IA picture will be completed automatically and should not be 
changed. Before invoking the HCE, the user should place a copy of the file ’c.c30.hce’ 
in the project directory. This file can be copied from the ’c:\ac100c30\station’ direc- 
tory on the AC100. The first screen of the HCE deals with inputs to the model and the 
second screen deals with the outputs. Inputs will initially show "MONITORINPUT’ 
as the ’type’ and are changed by selecting "Device_Type’. If the correct ’c.c30.hce’ 
file is in the current project directory, the user can use the arrow keys or the mouse to 
select the desired hardware for connection. The module field, ’mod’, will change to 1 
for all of the hardware options and must be changed to the correct module number. 
The module numbers differ according to which C30 is being used and are given in 
Table 6.1. Next the user selects the channel number, ’ch#’ which is 1 to 1000 for 
each of the serial ports and 1 to 16 for both the "IP_HiADC’ and the ’IP.PWM’. Each 





intse| Use middle mouse button on toggle items for pull-down menu’s. 
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14 roll_rate. MONITOR_INPUT o oO Oo 0 
|2 pitch comm MONITOR_INPUT 0 0 1.5708 1.5708 
i3 yawocomman MONITOR INPUT ° Oo °O re) 
4 theta.dist MONITOR_INPUT fo) ce) 0 ce) 
5 psi_dist MONT TOR. INPUT ie] (¢] (¢] (¢] 
6 roll_torqu MONITOR_INPUT ° 0 ie) 0 
17 pitch _torq MONITOR_INPUT ° (9) 0 0 
8 yaw_torque MONITOR _ INPUT 0 ° 0 c¢] 
9 rpm_settin MONITOR INPUT 0 (0) 6387.2 6387.2 
10 Vi-center IP_HiADC 1 2 e) fe) 
11 VY2_center IP .HiADC 4 4 fe} re) 
12 V3_center IP_HiADC 1 6 0 ce) 
13 V4_center IP_HiAdC 1 6 (¢) te) 
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Figure 6.6: Hardware Connection Editor 


"IP_SERIAL’ module has two serial ports referred to as ’chanA’ and ’chanB’. The 
‘ch#’ field refers to the data channel. Each input or output variable will require an 
individual channel. The AC100 Supplemental Reference Manual [Ref. 22] also talks 
about the hardware channel number. This number is a fixed value and refers to the 
hardware address of that I/O device. The outputs are initialized to NO-DEVICE’ 


and are connected in a similar manner. 
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TABLE 6.1: C30 HARDWARE MODULE NUMBERS 


[_______[ AGI00 [America ] 
[IPSERIAL | 2 or 3 [ 1or3_| 
[iPHiapcy 1 | 2 | 
LiPwM [4 > 4 







a. Serial Connections 


The SERIAL modules can be used for input and/or output [Ref. 22] 
pages 118-135. The serial modules were used for the Bluebird hardware-in-the-loop 
test and the AROD Flight Management Unit test. The Bluebird has an Inertial 
Measuring Unit which measures linear accelerations, angular rates, and euler angles. 
This information is available to the controller through a serial port. The serial 
information is a 40 byte string of hex characters terminated by a return character. 
This format differs from the format expected by the C30, however, the user can edit 
the ’user-_ser.c’ file and specify any desired format for the data. For more information 


on serial interfacing with the IMU see (Ref. 23]. 


b. Analog-to—Digital Connections 


The HiADC module is used for input only [Ref. 22] pages 110-117. Any 
analog voltage signal can be sampled and used by SystemBuild in a digital format. 
The SystemBuild block diagram can then use the input in units of volts, or convert 
the number to some other units. Section 3 below discusses the conversion from volts 


to degrees used for the AROD hardware-in-the-loop test. 
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c. Pulse Width Modulation Connections 


The PWM module has many uses for both input and output [Ref. 22] 
pages 105-109. Note that the actual name of this module is ’IP_68332’ but is referred 
to here as PWM’ since this is the only mode used for this report. In the PWM 
mode, the user specifies the duty cycle as the output from the SystemBuild diagram. 
The user can also edit the ’c.c30.hce’ file to specify the frequency of the pulses. The 
refresh frequency is integer parameter one which is labeled as 11 (column 10) under 
the output section of this file. Figure 6.7 depicts the relevant quantities for a PWM 


signal. 


bt 


+5V 


Figure 6.7: Timing Example for Pulse Width Modulation 


The spacing from the leading edge of one pulse to the next is called the 


period T, and is the inverse of the refresh frequency or: 


T=5 (6.1) 


The duty cycle is calculated as the percentage of time the pulse is "high’ which is +5 
Volts in this case. 


(6.2) 


t 
% Duty cycle = 7 
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The refresh frequency for the AROD hardware-in-the-loop test was chosen to be equal 


to the controller frequeucy of 40 Hertz. This gives a period T of 0.025 seconds or 
25 milli-seconds. The minimum pulse width required for the servos is approximately 
0.3 milli-seconds so: 


Min. % Duty Cycle = me = 0.012 (6.3) 


This corresponds to a vane deflection of —100 degrees. The maximum pulse width 


required for a +100 degree deflection is approximately 2.4 milli-seconds so: 


A 
Max. % Duty Cycle = = = 0.096 (6.4) 


The pulse width corresponding to a centered position, or zero degrees of deflection, 


is approximately 1.05 milli-seconds so: 


. 


Centered % Duty Cycle = = = 0.041 (6.5) 





Combining these gives: 
% Duty Cycle = 0.00041 - (Desired deflection in degrees) + 0.053 (6.6) 


The algebraic block ’degrees_to.-PWM’ included in each of the four vane SuperBlocks 


and shown in Figure B.10 implements Equaticn 6.6. 
3. Sensor Calibration 


Before the sensors can be used reliably b' ‘he controller, they must be 
calibrated. Due to small changes in the operating tages of the power supply, 
calibration is required each time the controller is started. For the original hardware- 
in-the-loop test, a separate C code program was run to calibrate the actuator sensors. 
Each time the controller is started the I/O devices must be initialized. This results 


in small changes in the measured voltages on the analog to digital I/O device from 
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one initialization to the next. For this reason the ‘chained’ JA picture was used so 


that the I/O would not have to be re-initialized after calibration. The procedure for 
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Figure 6.8: Interactive Animation Calibration Screen 
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calibration involves measuring the sensed voltage for vane positions of -100 deg, +100 
deg, and zero degrees. The model uses these measured voltages in the equation used 
to convert the measured sensor voltage into the correct vane position in degrees: 


200 


Vane position = (Vineas — Vo) X ———_—-——_ 
. ( OTs = Via 


(6.7) 
After starting the controller, the calibration routine is completed as follows: 


e The user clicks on the ’calibrate’ button to bring up the calibration screen. 
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e Next the user clicks on the ’Cal_mode’ switch which connects the calibration 


inputs to the actuators. 
e The voltage for 0 degrees is then entered in the ’V0’ input for each vane. 


e Next the position inputs are all changed to +100 degrees and the displayed 


voltage is input with the ’Plus 100’ bar for each vane. 


e Finally, the position inputs are all changed to -100 degrees and the "Minus 100’ 


inputs are changed accordingly. 


The user can then switch the ’Cal_Mode’ switch back to ’off’ and click on the Return’ 


button. 


4. Data Acquisition Editor 


A very useful feature of the AC100 is real-time data acquisition. The user 
can record any or al] of the inputs and outputs to a C30 project. In this way, the 
user can get a very detailed analysis of the performance of a particular model and/or 
controller. The user first selects "Data Acquisition Editor’ from the AC100 GUI, 
Figure 6.4. The user will be presented with the screen shown in Figure 6.9. To record 
an input, simply select ’ON’ under the ’setting’ column. If the ’decimation_factor’ is 
left at °1’ then the value of that input will be recorded every time step. To select an 
output, toggle the ’Display’ selector at the bottom of the screen from "SB.INPUTS’ 
to SBOUTPUTS’. When all of the desired inputs and outputs have been selected, 
click DONE’. The AC100 GUI will return. 

Once the user selects "Download and Run’, the "AC100 rtmpg Control Win- 
dow’ and the Interactive Animation display, Figure 6.5, will appear. To start record- 


ing data, the user selects START DATA ACQUISITION’. This will create a file in 
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Figure 6.9: Data Acquisition Editor 


the project directory with the project name and ’_l.raw’ appended. The number will 
be automatically incremented so that many data files may be collected. The but- 
ton will also change to STOP DATA ACQUISITION’. If data acquisition is started 
before Start Controller’, the data acquisition will begin with the first time step of 
the controller. Data acquisition stops automatically if the controller is stopped or 
rebooted. 

After selecting "REBOOT CONTROLLER’, the user is returned to the 
AC100 GUI. The user then selects Convert raw data’. This will create a file with 


the same name as the ’.raw’ file with ’.dat’ as the file extension. This data file can 





then be ioaded directly into MATRIX y. The MATRIX, variable names will be the 
same as those used as the input or output names in the SystemBuild model. These 
variables will be vectors with lengths depending on the amount of time that data was 


recorded. Plots of these variables are made the same as for any MATRIX, variable. 
C. CONNECTING THE HARDWARE 


Now that all of the software tools have been developed, the hardware must be 
physically connected to the control computer. Figure 6.10 shows the complete setup 
for the hardware-in-the-loop test using the AC100 Model C30. The SPARC work- 
station is the user’s main interface with the controller. The Interactive Animation 
picture is updated via the ethernet connection with the C30. The C30 runs the 
controller, the aircraft model, and interfaces with all of the hardware. 

The wiring harness was developed so that the first test flight of AROD could 
be done with the control computer remaining on the ground and connected to the 
AROD with a tether. The wiring harness and tether are designed to supply power 
to the AROD and to pro-ide all of the control signals and return all of the sensor 
outputs. Figure 6.11 shows the connector end of the tether. For this test, only the 5 
volt power lines and the vane signals were used. 

The servo motors have two sets of wires emerging from the case. Each set 
contains a red, white, and black wire. The wires attached to the narrow side of the 
servos are the input wires and the wires attached to the wide side are the sensor 
outputs. Table 6.2 lists the function of each of these wires. 

The pin diagrams for each of the C30 Modules are in [Ref. 22]. Figure 6.12 
shows the complete wiring for the AROD hardware-in-the-loop test on the C30. The 


wiring harness box is a PC shell containing screw terminal blocks and a PC power 
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Figure 6.10: AC100 Model C30 Hardware—-In—-The—Loop Setup 


supply as well as a 24 Volt power supply. The wire connections internal to the wiring 


harness are not shown. 








1. Vane #1 signal 13. #24 Volt Power 
2. Vane #2 signal 14. 24 Volt Ground 
3. Vane €3 signal 15. sheild 

4. Vane @4 signal 16. Vane @1 Sensor 
S. Phrottle signal 17. Vane @2 Sensor 
6. Pitch Signal 18. vane @3 Sensor 
7. Yaw Signal 19. Vane @4 Sensor 
S. Kill switch 20. 

9. Kill switch 21. Roll Rate Sensor 
10. Tachometer 22. Pitch Rate Sensor 
11. +5 Volt Power 23. Yaw Rate Sensor 
12. 5 Volt Ground 24. 


Figure 6.11: Connector on end of Wiring Harness Tether 


TABLE 6.2: SERVO MOTOR WIRING 


[| Control Inputs | Sensor Outputs 
[Red [+5 Volts | High Tap 
Black [Ground | Ground 
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Figure 6.12: AC100 Model C30 Hardware-In-The-Loop Test Wiring Dia- 
gram 








VII. RESULTS, CONCLUSIONS, AND 
RECOMMENDATIONS 


A. HARDWARE-IN-THE-LOOP TEST RESULTS 


The hardware-in-the-loop test of N. Sivashankar’s controller showed the con- 
troller to be unstable. Analyzing the actuators as discussed in Chapter V revealed 
that the controller was changing the commanded position of the vanes faster than 
the vanes could respond. The controller gain was re-computed using the original syn- 
thesis model and the H,, theory procedure outlined in Chapter IV Section A. The 
cost function weighting matrices were adjusted to reduce the control loop bandwidth 
to less than 2 radians to account for the limited performance of the actuators. The 
resulting bandwidth for the control and command loops are compared to the originals 
in Figure 7.1. The first three sub-plots show the old (solid) and new (dashed) control 
loop bandwidth. The second three sub-plots show the old and new command loop 
bandwidth. 

The new control gain was then entered into the controller and tested. The 
hardware-in-the-loop test of the new controller was successful and showed slower 
responses to disturbances as expected. For a comparison, the new controller was 
subjected to the same series of disturbances as the original controller. Figure 7.2 
shows the SystemBuild disturbance rejection plot from the original controller. The 
hardware-in-the-loop disturbance rejection plot is similar with some noise [Ref. 3] 
but was not available for reproduction in this report. The disturbances introduced 


for all of these tests are listed in Table 7.1. Figure 7.3 shows the pitch and yaw errors 
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recorded from the hardware-in-the-loop test of the new controller. Notice that there 


is relatively little noise in the new controller due to the new sensor design. 


TABLE 7.1: PITCH AND YAW DISTURBANCES IN RADIANS 


[Time (seconds) | 0 [4] 9 [3] 
[ Pitch Disturbance [0.1 [02[ 0 [02] 
[Yaw Disturbance |-O.1] 0 [-02[02 | 





B. CONCLUSIONS 


Based on the data presented in this thesis the following conclusions are drawn: 


e Automation using the AC100 Model C30 dramatically improves the time to 
first prototype. Valuable time is saved by not having to write code for the 
control computer and the hardware I/O drivers. The user only needs a basic 
understanding of the hardware and it’s requirements. All required code is 


generated automatically by the AC100 software. 


e Improvements to the model or controller can be implemented and tested imme- 
diately. For the same reasons as above, any changes made at the block diagram 


level can be tested immediately with a few mouse clicks. 


e Real-time data acquisition allows for detailed analysis of test results. Since all 
of the inputs and outputs can be recorded at each time step, the data can be 
scrutinized thoroughly after a test. This is a tremendous help when trying to 


find errors created by improper timing. 


e Hardware-in-the-loop testing does not fully validate a controller if the test is 
not performed real-time. The original controller was considered stable after 


initial hardware-in-the-loop testing, but was not stable when tested real-time. 
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C. RECOMMENDATIONS 


Considering the conclusions introduced above and the experience gained while 


conducting this thesis, the following recommendations are made: 


Investigate sending IA data to additional ethernet address and capturing data 
for Virtual Prototying on Designer’s Workbench. Previous thesis work has 
demonstrated the extraordinary benefits of Virtual Prototyping. Presently the 
data from an AC100 Model C30 hardware-in-the-loop test would have to be 
recorded and then moved to ancther file for use by Designer’s Workbench. 
Sending data directly from the AC100 Model C30 to Designer’s Workbench 
would allow real-time 3-Dimensional representation of the hardware-in-the-loop 


test data. 


Investigate using graphics programs with C30 for field display of data. Cur- 
rently the AC100 Model C30 sends all of the test data to the workstation for 
display. The AC100 Model C30 would be very useful for a tethered flight test 
of the AROD, however, this would currently require a portable workstation to 
display the data from the AC100 Model C30. The data could easily be dis- 
played on the AC100 Model C30 display with the use of a DOS or Windows 


graphics interface. 


Incorporate the AC100 Model C30 into the avionics design course work. Valu- 
able experience is gained when testing a controller with hardware-in-the-loop . 


Students learn to consider all of the requirements for interfacing such as: 


— signal conversion (i.e., analog to digital, volts to degrees, degrees to PWM, 


etc.) 
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— power requirements 


timing (when control signals are generated vice when the sensor output is 


available) 


— interference (interaction of control signals, Radio Frequency interference) 





data bandwidth (information required verses information available 
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A. GET_XDOT.M 


APPENDIX A 
MATLAB FILES 


function [| x_dot] = get_xdot(invect) 


% 


% Function computes x_dot given an input vector which is x and u_c 


% muxed together. u_c is first four and x is last nine. The inputs 


% order is elevator, rudder, aileron, rpm-setting. The states are 


% wu, Vv, W, p, q, ©, phi, theta, psi. 


% 


WAM MW%% First step is to demux the input vector 


u_c=invect(1:4); 


% u-c(1)=deltae (elevator) 
% u-c(2)=deltar (rudder) 


% u.c(3)=deltaa (aileron) 


drpm = u-c(4); % (throttle) 


v=invect(5:7); 

% v(l)=u (x velocity) 
% v(2)=v_ (y velocity) 
% v(3)=w (z velocity) 


omega=invect(8:10); 
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p=omega(1); %(roll rate) 
q=omega(2); %(pitch rate) 


r=omega(3); %(yaw rate) 


lambda=invect(11:13); 
phi=lambda(1); ‘%(bank angle) 
theta=lambda(2); %(pitch angle) 


psi=lambda(3);  _%(yaw angle) 


x=[v; omega; lambda; ] ; 


AWAMM%% Next get constant values for: 
% m,Ib,Ir,$,Cfo,dCfdx,dCfdd,M1,rho,Ar,g 

% 

const val; 


% constval is a Matlab script file, not a function, and sets the 


% values in the Matlab environment for use by all functions. 


AKAnWhDAN% Form omega cross matrix and compute Vt and q 
wx=[0-rq;1r0-p;-qp 0]; 

Vt=sqrt(v(1)A 2+vi2)A 2+v(3)A 2); 

qbar=.5* rho* VtA 2; 


ANWW%%% Form sine and cosine abreviations 
% 

ch=cos(phi); 

sh=sin(phi); 
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ct=cos(theta); 
st=sin(theta); 
cs=cos( psi); 


ss=sin(psi); 


MhMhhAW%% Form force due to gravity 

% B U 

% R* F — = force due to gravity, moment = 0 
% U g 

% 

% 2-3-1 rotation 

% 


RubF g=[ -cs* st+ g 
(ch* ss* st-+sh* ct)* g 


(chx ct-sh* ss* st)* g |; 


AhhhLW%% Form Rwb (transform wind coordinates to body 

alpha=asin(v(2)); 

beta=-asin(v(3)); 

Rwb=[ cos(alpha)* cos(beta) -cos(alpha)+ sin(beta) -sin(alpha) 
sin(beta) cos(beta) 0 


sin(alpha)* cos(beta) -sin(alpha)* sin(beta) _cos(alpha) | ; 


AWKWWV%%% System is of the form 

% 

% x=Ax+Bu+C where u is the control inputs and 
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% C is a combination of gravity and 
% other influences 

% 

AVT%N% Form ”A” matrix 

% 

%h%% USING THRUST VS RPM FROM BOB STONEY’S TEST RUNS 
% 

T=0.0297+ drpm-104.7; 

% 

Vi=sqrt(T/2/Ar/rho); 

% 

% NOTE: derivatives are non-dimentionalized with qi (induced velocity) 

% so add u to the induced velocity for total q 

% 

qt=.5* rhox (v(1)+Vi)A 2; 

% 

It=Ib-+Ir; 

O=zeros(3,3); 

I=eye(3); 

% 

% The generic ‘A‘matrix would be: 

% A=([-wx O; O -It\ (wx» It)] + [ (I/m)* Rwb O; O It\ Rwb | * q« S* dCfdx« 
M1); 

% 

A=[ -wx O; O -It\ (wx« It)] ; 
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% 
AAKN Form ”B” matrix 
% 


% Note: control surface derivatives are non-dimentionalized using 

% characteristic lengths from rotor 

% 

B1=| (I/m)* Rwb O; O It\ I] * qt+ Sd« dCfdd: 

% 

%%%%% LT relates the duct swirl to the moment | produced by thrust 
% 

LT=-0.0542* T-0.9138; 

wr=| drpm* 2« pi/60;0;0] ; 


% 

B2=| T/m; 0; 0; -It\ ([ LT; 0; 0;] +(wx« Ir* wr)) ] ; 
% 

AAWN% Form ”C” matrix 

% 


% Generic ‘C‘matrix would be 

% C=| (I/m)« RubFg; 0;0;0; } +{ (I/m)+ Rwb O; O It\ Rwb } + qbars S* Cfo; 
% 

C=[ RubFg; 0;0;0; ] ; 

% 

hhW% Form Drag matrix 

% 


% Note: this is not aerodynamic drag, this is an estimate of the 
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% parasitic drag elements. 

% 

sb=6.7708; 

s=§(2,2); 

su=sign(v(1)); 

sv=sign(v(2)); 

sw=sign(v(3)); 

sp=sign(p); 

sq=sign(q); 

sr=sign(r); 

Sdrag=diag([ su* Ar,sv* sb,sw* (s+sb),sp* .5* s,sq* .7* (s+sb),sr# .5* sb] ); 
Vm=[ (v.A 2)/m; It\ (omega.A 2) | ; 
D=rhox diag(Cfo)* Sdrag+ Vm; 


ANAM %% Form lambda dot using 2-3-1 rotation 
% 
Idot=[ p-q* ch ss/cs+r* sh* ss/cs 

q* ch/cs-r* sh/cs 

q* sh+r* ch Is 


AWN % TL%%% Form totals 
% 
vw.dot=A+ [ v; omega ] +Bl* u_c(1:3)+B2+C+D; 


x_dot=[ vw-dot; Idot; } ; 
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B. CONSTVAL.M 


% 

% [ m,Ib,Ir,S,Sd,Cfo,dCfdx,dCfdd,M1,rho,Ar,g] 

% 

% This file returns all of the constants for the arod EOM 


% Hover condition =) all aero derivatives are zero 


% Total body mass 
m=2.6419; % slugs 


% Body mass moment of inertia 


Ib=[ 1.2312 0 0; 0 3.9548 0; 0 0 3.9825 | ; Mslug ftA 2 


% Prop mass moment of inertia 


Ir=[ 0.00898 0 0; 0 0.0045 0; 0 0 0.0045 | ; %slug ftA 2 


% Standard length matrix for wings 
ss=9.4444: bw=5.7; cbarw=2.165; 


S=diag([ -ss,ss,-ss,ss* bw,ss* cbarw,ss* bw] ); 
% Standard length matrix for contro] surfaces 
sp=pi; bp=1; cbarp=1; 

Sd=diag(| -sp,sp,-sp,sp* bp,sp* cbarp,sp+* bp] ); 


% Cfo (used as a drag term in all three axes 


Cfo=[ -.015; -.015; -.015; -0.015; -0.015; -0.015; ] ; 


% dCf/do. 
dCfdx=0; 





% aCf/dx.dot=0 for this model 
% dCfdxd=[ ]; 


% dCf/ddelta 
dCfdd=[ zeros(3,3); 0 0 1.438; -1.233 0 0; 0 -1.233 0) ; 


% Mi 

Vt=1, 

M1=diag([ 1/Vt,1/Vt,1/Vt,bw/(2* Vt),cbarw/(2* Vt),bw/(2* Vt)]} ); 
% rho 

rho=.002377; %slugs/ftA 3 

% area 

R=1; 

Ar=pix R; 

% gravity 

g=32.174; %ft/secA 2 
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APPENDIX B 
MATRIX, BLOCK DIAGRAMS 


A. AROD SystemBuild BLOCK DIAGRAMS 


The AROD SystemBuild block diagram contains the following SuperBlocks: 


actuators: Figure B.1 shows the SuperBlock containing 4 actuator SuperBlocks, 


one for each vane. 


actuator_1: Figure B.2 shows the actuator model for the first vane and is 


identical to the other vane actuators. 
actuator_2: Not shown. 
actuator_3: Not shown. 
actuator_4: Not shown. 


ang-_velocity_eq: Figure B.3 shows the SuperBlock for the angular velocity 
equations. The values for the body and rotor inertia matrices are listed in 


Table 2.1. 


dcont_wind: Figure B.4 shows the controller SuperBlock for the AROD. The 
saturation block limits the throw of the vanes to +15 degrees. The two algebraic 
blocks convert the command signals to vanes signals in degrees, and the vane 


signals back to command signals in radians respectively. 


filters: Figure B.5 shows the four anti-aliasing filters discussed in Chapter V 


Section E. The values for the four vane filters are given in Equation 5.8. 
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e integ_ang-_vel: Not shown. 
e integ_lin_vel: Not shown. 


e Integ-sim: This SuperBlock contains the SuperBlocks ‘integang-vel’, ’in- 
teg_lin_vel’, and ’int_ang-sim’. Each of these SuperBlocks contain three dis- 
crete integrators as shown in Figure 3.2 with the appropriate initial values. 
The ’int_ang_sim’ SuperBlock also contains two sum blocks to add in the per- 


turbations for @ and wp. 
e int_ang-sim: Not shown. 


e kinematics: Figure B.6 shows the kinematics SuperBlock which contains the 


lin_velocity eq’, ’ang_velocity eq’, and ’L_dot_eq’ SuperBlocks. 


e lin_velocity_eq: Figure B.7 shows the equations for the linear forces acting 
on the aircraft. The ’T_value’ SuperBlock contains Equation 3.1 and block 95 


is the force due to gravity. 
e L_dot_eq: Not shown. This SuperBlock is an implementation of Equation 2.58. 


e |_m_n-_compute: Figure B.8 computes the angular momentum terms. Blocks 
5, 6, and 98 contain the appropriate stability derivatives and block 7 includes 


the moment due to propeller thrust given in Equation 3.2. 


e nl_tst4_hw: Figure B.9 shows the top level SuperBlock for the hardware-in- 
the-loop test. The inputs and outputs from this SuperBlock are listed in the 


’nl_tst4_hw.rtf’ file and used in the Hardware Connection Editor. 


e T_value: Not shown. This SuperBlock is Equation 3.1. 
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vanel: Figure B.10 shows the Superblock for vane one and is identical to the 
other three SuperBlocks. Block 6 shows the conversion from degrees to percent 
duty cycle discussed in Section c of Chapter VI. Block 4 is the algebraic block 


discussed in Section 3 of Chapter VI. 
vane2: Not shown. 
vane3: Not shown. 
vane4: Not shown. 


vane4x: Figure B.11 shows the ’vane4x’ SuperBlock which contains a Su- 


perBlock for each of the four vanes and the ’filters’ SuperBlock. 
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